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(57) Abstract 



A highly scalable key management architecture for secure client-server systems used in IP telephony network, wherein cryptographic 
state needs to be saved only by the clients. This architecture takes advantage of existing key management protocols, Kerberos with 
the PKINIT (public key) extension, to provide an IP telephony system having a high degree of scalability. In the case of lost security 
associations, the architecture provides for lightweight rekeying operations that allow clients to quickly re-establish the lost association or 
switch to a different server. TTie key management architecture includes a method for establishing a secure channel between an IP telephony 
endpoint and Server in an IP telephony network. The endpoint is coupled to a user and the Server is coupled to the IP telephony network. 
The method comprises steps of transmitting from the endpoint to a key distribution center a request for a security ticket, receiving the 
security ticket from the key distribution center, transmitting from the endpoint to the Server a request for a sub-key, receiving the sub-key 
from the Server, and establishing a secure channel between the endpoint and the Server using the sub-key. 
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KEY MANAGEMENT BETWEEN A CABLE TELEPHONY 
ADAPTER AND ASSOCIATED SIGNALING CONTROLLER 

CROSS-REFERENCES TO RELATED APPLICATIONS 
This application claims priority from co-pending U.S. Provisional Patent 
Application Serial No. 60/128,772 filed April 9, 1999, the disclosure of which is 
incorporated herein in its entirety for all purposes. 

FIELD OF THE INVENTION 

This invention relates generally to key management for Client-Server 
systems, and more particularly, to a scalable key management system for use in IP 
telephony networks. 

BACKGROUND OF THE INVENTION 
In an Internet Protocol (IP) telephony network, a network server may be 
responsible for setting up phone calls with up to 100,000 clients. The clients may be 
coupled to the telephony network via cable telephony adapter (CTA) devices. In order to 
secure call signaling, an Internet Protocol Security (IPSec) association is set up between 
each client and the server. This has to be done in a timely fashion to minimize the CPU 
overhead at the server and to minimize the call setup delay. 

In order to handle large numbers of clients, key management needs to be 
as fast as possible. For example, security associations might be lost when a server goes 
down or become too busy to handle all of its clients. The lost security associations must 
then be re-establish again when needed. Manual administration of clients is unsuitable 
because of the high overhead costs and lack of scalability. Other techniques used in 
architectures unrelated to IP telephony are also not suitable, since they do not provide the 
desired scalability and low administration overhead. 



07/22/2004, EAST Version: 1.4.1 



wo 00/62507 



PCT/USOO/09323 



2 

SUMMARY OF THE INVENTION 
The present invention includes a highly scalable key management 
architecture for secure client-server systems used in IP telephony network, wherein 
cryptographic state needs to be saved only by the clients. This architecture takes 
advantage of existing key management protocols, Kerberos with the PKINIT (public key) 
extension, to provide an IP telephony system having a high degree of scalability. In the 
case of lost security associations, the architecture provides for lightweight rekeying 
operations that allow clients to quickly re-establish the lost association or switch to a 
different server. 

In one embodiment of the present invention, a method for establishing a 
secure channel between an IP telephony endpoint and Server in an IP telephony network 
is provided. The endpoint is coupled to a user and the Server is coupled to the IP 
telephony network. The method comprises steps of transmitting from the endpoint to a 
key distribution center a request for a security ticket, receiving the security ticket from the 
key distribution center, transmitting from the endpoint to the Server a request for a sub- 
key, receiving the sub-key from the Server, and establishing a secure channel between the 
endpoint and the Server using the sub-key. 

A fiirther understanding of the nature and the advantages of the inventions 
disclosed herein may be realized by reference to the remaining portions of the 
specification and the attached drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 
FIG. 1 shows a telephony network constructed in accordance with the 

present invention; 

FIG. 2 shows message exchange diagram for establishing a secure 
communication chaimel in accordance with the present invention; and 

FIG. 3 shows a method for establishing a secure communication channel 
using the messages of FIG. 3. 

DESCRIPTION OF THE SPECIFIC EMBODIMENTS 
Embodiments of the present invention provide for establishing a secure 
channel between an IP telephony endpoint and a Server in an IP telephony network. In 
the embodiments discussed herein, a cable telephony adapter (CTA) device is 
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representative of the IP telephony endpoint and a Signaling Controller (SC) is 
representative of the Server. However, the present invention is suitable for use with other 
types of network endpoints and Servers not discussed herein. 

FIG. 1 shows a portion of a telephony network 100 constructed in 
accordance with the present invention. To access the telephony network, CTA 102 
provides access to a user 104 via a Hybrid Fiber/Coax (HFC) head-end 106. The HFC 
head-end 106 has the capacity to provide access to other users as shown at 108, The HFC 
head-end is also coupled to a Signaling Controller (SC) 1 10 which is coupled to a 
telephony network backbone 114. The Signaling Controller is used to control the CTA's 
access to the telephony network. A key distribution center (KDC) 1 12, is also coupled to 
the telephony network backbone 1 14. The KDC 1 12 issues Kerberos tickets, which are in 
turn used to generate sub-keys for secure connection protocols, such as the IPSec 
encapsulating security payload (ESP) protocol, or other secure connections. The network 
100 also includes a customer service representative (CSR) center 116, a provisioning 
certification authority (CA) 11 8 and a billing host 120. Thus, in the network 100 it is 
possible for the user 104 to access the telephony backbone 1 14 via the CTA 102 using a 
secure protocol. 

Embodiments of the present invention include the use of the Kerberos 
protocol with the public key PKINIT extension for key management. This protocol is 
based on Kerberos tickets, which are cookies, encrypted with the particular server's key. 
The Kerberos ticket is used to both authenticate a cHent to a server and to establish a 
session key, which is contained in the ticket. Accessing Kerberos services can be done 
using the Generic Security Service Application Program Interface (GSS-API) standard. 

In one embodiment of the present invention, two-way authentication with public 
key certificates is used by the CTA to obtain a Signaling Controller ticket from the KDC. 
A corresponding session key is delivered to the CTA sealed with either the CTA*s public 
key or with a secret derived from a Diffie-Helhnan exchange. The Signaling Controller 
ticket is kept for a relatively long period of time, for example, days or weeks. The length 
of this period can be adjusted based on network performance requirements. In addition, 
the Signaling Controller ticket is used to establish a symmetric session key, which is in 
turn used to establish a set of keys for use with the IPSec ESP mode. The keys used by 
IPSec are not derived from the session key itself Instead, another random key (i.e., a 
sub-key) is generated for each phone call and then used to derive the IPSec keys. Thus, 
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the Signaling Controller does not have to keep state. After it derives all the required keys 
from the sub-key and exchanges signahng messages with the CTA, the Signaling 
Controller can throw away the ticket along with all of the associated keys. 

The use of the Kerberos protocol with the PKINIT extension in 
embodiments of the present invention provides several advantages. For example, the 
Signaling Controller is not required to keep state - Kerberos tickets need to be kept only 
by the endpoints (CTAs). Also, IPSec Security Associations can be torn down when no 
longer needed and quickly re-established with efficient key management based on the 
Kerberos tickets. The protocol runs over both TCP and UDP protocols, and is a widely 
available standard, with multiple vendors providing support for both Kerberos and 
PKINIT. 

In one embodiment, within the PKINIT protocol, RSA is used for both key 
delivery and authentication. In another embodiment, a PKINIT option may be used 
wherein Diffie-Helhnan is used for the key exchange and RSA is used for authentication, 
bi general, embodiments of the present invention are suitable for use wixh any pubUc key 
algorithms within PKINIT for both authentication and key exchanges. 

FIG. 2 shows a message exchange diagram 200 illustrating how the CTA 
uses Kerberos to obtain the sub-key, which in turn, is used to derive IPSec ESP keys for 
the CTA-to-Signaling Controller signaling messages. In the exchange diagram 200, only 
some of the information carried in the messages is provided in order to present a clear 
description of the protocol. The exchange diagram 200 shows messages transmitted or 
received at the CTA 102 at line 220, the KDC 112 at Ime 222, and the Signaling 

Controller 110 at line 224. 

FIG. 3 shows a flow diagram 300 illustrating how the messages of FIG. 2 

are exchanged in accordance with the present invention. 

At block 302, a PKINIT Request is sent from the CTA 102 to the KDC 
1 12 as shown by message 202. This request includes the CTA signature and certificate - 
used by the KDC to authenticate the CTA. This request also carries the current time - 
used by the KDC to verify that this message is not a replay or a retransmission of an old 
message. The PKINIT Request also contains a random value (called a nonce) that will be 
used to bind a subsequent PKINIT Reply message to this request. In the case that a 
Diffie-HeUman exchange is used, the CTA will also include its Diffie-Helhnan 
parameters and public value in the PKINIT Request. 
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At block 304, the KDC 1 12 receives and verifies the PKINTT Request and 
then issues to the CTA a ticket for the Signahng Controller encrypted v/ith the Signaling 
Controller's service key. Inside this encrypted ticket are a symmetric session key, its 
validity period and the CTA identity. Also in this step, this ticket will be sent back to the 
5 CTA 102 inside a PKINIT Reply, shown by message 204. The PKINIT Reply message 
also contains KDC's certificate and signature for authenticating the KDC, along v^ith the 
nonce from the PKINIT Request to protect against replays. If a Diffie-Helhnan exchange 
is used, the KDC also places its Diffie-Hellman public value into this message. 

The PKINIT Reply also contains a second copy of the session key and its 
10 validity period found in the ticket - intended to be decrypted and used by the CTA. This 
second copy of the session key and its associated attributes are either encrypted w^ith a 
Diffie-Helhnan-derived secret or enveloped with the CTA's public key. Here, enveloped 
means that the session key along with its associated attributes are not encrypted directly 
with the CTA's pubUc key. Within the PKINIT Reply the public key is used to encrypt a 
15 random symmetric key that is in turn used to encrypt another symmetric key which is 
then finally used to encrypt the session key and its attributes. This embodiment uses the 
PKINIT standard as is, even though in this case, simplifications to the PKINIT Reply 
seem possible. If a Dififie-Hellman exchange is not used, then the Reply contains 
message items as showTi at 226. 
20 At block 306, an application (AP) Request is sent fi-om the CTA 1 02 to the 

Signahng Controller 1 10 as shovm by message 206. Here, a CTA has aheady obtained a 
Signaling Controller ticket and now initiates key management with the Signaling 
Controller by sending it an AP Request message. The AP Request contains the Signaling 
Controller ticket along with the CTA name, timestamp and a message hash - all 
25 encrypted with the SC session key. The timestamp is used to check for replays of old AP 
Request messages. 

At block 308, the Signaling Controller 110 receives an AP Request. It first 
decrypts and validates the ticket with its service key. It then takes the session key out of 
the ticket and uses it to decrypt and validate the rest of the AP Request. Then, the 
30 Signaling Controller generates a random sub-key and encrypts it along with the current 
timestamp with the session key. It places this information into an AP Reply message 208 
and sends it back to the CTA. 
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At block 310, the CTA receives and validates the AP Reply, after which it 
shares the sub-key with the Signaling Controller. Both sides independently derive (with 
some one-way function) a set of IPSec encryption and authentication keys from this sub- 
key. After that, all signaling messages between the CTA and the Signalmg Controller 
5 will be protected with an IPSec channel. This estabhshment of the IPSec channel is 
symbolically illustrated in FIG. 2 at 210 - even though this step does not involve an 
exchange of messages. 

In the embodiment of the invention depicted in FIGS. 2 and 3, the PKINIT 
exchange is performed at long intervals in order to obtain an intermediate symmetric 
10 session key. This session key is shared between the CTA and the Signaling Controller 
(via the Signaling Controller Ticket). 

In this embodiment, the PKINIT Request/Reply messages, shovra at 202 
and 204, are sent over a TCP/IP connection. This is because a single PKINIT Request or 
Reply message, containing public key and Diffie-Hellman information may be too large 
1 5 to fit into a single UDP packet. The use of TCP instead of UDP may have some impact 
on performance, but since the PKINIT exchange occurs at infirequent intervals (days or 
weeks apart) and is not tied to the phone calls, the impact on performance is not 
significant. 

The session key is used in the AP Request and AP Reply messages, shown 
20 at 206, 208 and are exchanged for each phone call, to establish a symmetric sub-key. 
This sub-key is used to derive all of the IPSec ESP keys and starting sequence numbers, 
used for both directions. The AP Request and AP Reply messages are small enough to fit 
into a single UDP packet, and thus will run over UDP. 

The present invention provides a highly scalable key management 
25 architecture for secure client-server systems used in IP telephony networks. It will be 
apparent to those with skill in the art that modifications to the above methods and 
embodiments can occur without deviating fi-om the scope of the present invention. 
Accordingly, the disclosures and descriptions herein are intended to be illustrative, but 
not limiting, of the scope of the invention which is set forth in the following claims. 
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WHAT IS CLAIMED IS: 



1 1 . A method for establishing a secure channel between an IP 

2 telephony endpoint and Server in an IP telephony network, wherein the endpoint is 

3 coupled to a user and the Server is coupled to the IP telephony network, the method 

4 comprising steps of: 

5 transmitting from the endpoint to a key distribution center a request for a 

6 security ticket; 

7 receiving the security ticket from the key distribution center; 

8 transmitting from the endpoint to the Server a request for a sub-key; 

9 receiving the sub-key from the Server; and 

1 0 establishing a secure channel between the endpoint and the Server using 

1 1 the sub-key. 

1 2. The method of claim 1 , wherein the endpoint is a cable telephony 

2 adapter. 

1 3. The method of claim 1 , wherein the server is a Signaling 

2 Controller. 

1 4. The method of claim 1 , wherem the secure channel is an IPSec 

2 channel. 
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